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Abstract 


This document provides guidelines for achieving end-to-end Quality of 
Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access 
network is based on IEEE 802.11. RFC 7222 describes QoS negotiation 
between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) 
in a PMIPv6 mobility domain. The negotiated QoS parameters can be 
used for QoS policing and marking of packets to enforce QoS 
differentiation on the path between the MAG and LMA. IEEE 802.11 and 
Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for 
QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) 
and an Access Point. This document provides a mapping between the 
above two sets of QoS procedures and the associated QoS parameters. 
This document is intended to be used as a companion document to RFC 
7222 to enable implementation of end-to-end QoS. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7561. 
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1. Introduction 


PMIPv6 QoS [1] describes an access-network-independent way to 
negotiate Quality of Service (QoS) for Proxy Mobile IPv6 (PMIPvé6) 
mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM), and Wi-Fi 
Multimedia - Admission Control (WMM-AC) describe ways to provide QoS 
for Wi-Fi traffic between the Wi-Fi Station (STA) and Access Point 
(AP). This document describes how QoS can be implemented in a 
network where the access network is based on IEEE 802.11 (Wi-Fi). It 
requires a mapping between QoS procedures and information elements in 
two segments: 1) the Wi-Fi segment and 2) the PMIPv6 segment. (See 
Figure 1.) The recommendations here allow for dynamic QoS policy 
information per Mobile Node (MN) and session to be configured by the 
IEEE 802.11 access network. PMIPv6 QoS signaling between the Mobile 
Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the 
per-MN QoS policies in the MAG. Further details on policy 
configuration and the Policy Control Function (PCF) can be found in 
[1], Section 6.1. In the IEEE 802.11 access network modeled here, 
the MAG is located at the AP / Wireless LAN Controller (WLC). 

Figure 1 below provides an overview of the entities and protocols. 


4+----- + 4+------- + 
| AAA | | PCF | 
4+--+--4+ 4+---+---+ 

| | 
| | 
4+----+ 4+--+-------- + 4+---+---+ 
| IEEE 802.11, WMM-AC |+-++ +---+| PMIPv6§ | 
MN <---------------------- > | AP+--+MAG|<==========> LMA 
| | (ADDTS, DELTS) |+--+ +---+| Qos | | 
4+----+ 4+----------- + 4+------- + 


Figure 1: End-to-End QoS in Networks with IEEE 802.11 Access 


The MN and Access Point (AP) use IEEE 802.11 QoS mechanisms to set up 
QoS flows in the Wi-Fi segment. The MAG and LMA set up QoS flows 
using PMIPv6 QoS procedures. The protocols and mechanisms between 
the AP and MAG are outside the scope of this document. Some 
implementations may have the AP and MAG in the same network node. 
However, this document does not exclude various deployments including 
those in which the AP and WLC are separate nodes or in which the MAG 
control and data planes are separate. 


The recommendations in this document use IEEE 802.11 QoS and PMIPv6 
QoS mechanisms [1]. State machines for QoS policy setup in IEEE 
802.11 and PMIPv6 operate differently. Guidelines for installing QoS 
in the MN using IEEE 802.11 and PMIPv6 segments and for mapping 
parameters between them are outlined below. 
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— Procedure Mapping: 


PMIPv6-defined procedures for QoS setup, as specified in [1], may 
be triggered by the LMA or MAG. IEEE 802.11 QoS setup, on the 
other hand, is always triggered by the MN (IEEE 802.11 QoS 
Station (QSTA)). The end-to-end QoS setup across these network 
segments should accommodate QoS that is triggered by the network 
or by the end user. 


—- Parameter Mapping: 


There is no systematic method of mapping of specific parameters 
between PMIPv6 QoS parameters and IEEE 802.11 QoS. For example, 
parameters like Allocation and Retention Priority (AARP) in 
PMIPv6 QoS have no equivalent in IEEE 802.11. 


The primary emphasis of this specification is to handle the 
interworking between WMM-AC signaling/procedures and PMIPv6 QoS 
signaling/procedures. When the client does not support WMM-AC, then 
the AP/MAG uses the connection mapping in Table 2 and DSCP-to-AC 
mapping as shown in Table 3. 


The rest of the document is organized as follows. Section 2 provides 
an overview of IEEE 802.11 QoS. Section 3 describes a mapping of QoS 
Signaling procedures between IEEE 802.11 and PMIPv6é. The mapping of 
parameters between IEEE 802.11 and PMIPv6 QoS is described in 

Section 4. 


1.1. Abbreviations 


AAA Authentication, Authorization, and Accounting 
AARP Allocation and Retention Priority 
AC Access Category 

ADDTS ADD Traffic Stream 

AIFS Arbitration Inter-Frame Space 

ALG Application Layer Gateway 

AMBR Aggregate Maximum Bit Rate 

AP Access Point 

CW Contention Window 

DELTS DELete Traffic Stream 

DL DownLink 

DSCP Differentiated Services Code Point 
DPI Deep Packet Inspection 

EDCA Enhanced Distributed Channel Access 
EPC Evolved Packet Core 

GBR Guaranteed Bit Rate 

MAC Media Access Control 

MAG Mobile Access Gateway 
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MBR Maximum Bit Rate 

MN Mobile Node 

MSDU Media Access Control Service Data Unit 

PBA Proxy Binding Acknowledgement 

PBU Proxy Binding Update 

PCF Policy Control Function 

PHY Physical Layer 

QCI QoS Class Identifier 

Qos Quality of Service 

QSTA QoS Station 

SIP Session Initiation Protocol 

STA Station 

TC Traffic Class 

TCLAS Type Classification 

TCP Transmission Control Protocol 

TS Traffic Stream 

TSPEC Traffic Conditioning Specification 

UDP User Datagram Protocol 

UL UpLink 

UP User Priority 

WLAN Wireless Local Area Network 

WLC Wireless Controller 

WMM Wi-Fi MultiMedia 

WMM-AC Wi-Fi MultiMedia Admission Control 
Definitions 

Peak Data Rate 
In WMM-AC, Peak Data Rate specifies the maximum data rate in bits 
per second. The Maximum Data Rate does not include the MAC and 
PHY overheads [4]. Data rate includes the transport of the IP 
packet and header. 
TSPECs for both uplink and downlink may contain Peak Data Rate. 

Mean Data Rate 


This is the average data rate in bits per second. The Mean Data 
Rate does not include the MAC and PHY overheads [4]. Data rate 
includes the transport of the IP packet and header. 


TSPECs for both uplink and downlink must contain the Mean Data 
Rate. 
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Minimum Data Rate 


In WMM-AC, Minimum Data Rate specifies the minimum data rate in 
bits per second. The Minimum Data Rate does not include the MAC 
and PHY overheads [4]. Data rate includes the transport of the IP 


packet and header. 


Minimum Data Rate is not used in QoS provisioning as it is 
described here. 


QCI 


The QoS Class Identifier (QCI) is a scalar parameter that points 
to standardized characteristics of QoS as opposed to signaling 
separate parameters for resource type, priority, delay, and loss 


[8]. 


STA 


A station (STA) is a device that has the capability to use the 
TEEE 802.11 protocol. For example, a station maybe a laptop, a 
desktop PC, an access point, or a Wi-Fi phone [3]. 


An STA that implements the QoS facility is a QoS Station (QSTA) 
[3]. 
TSPEC 


The TSPEC element in IEEE 802.11 contains the set of parameters 
that define the characteristics and QoS expectations of a traffic 


flow [3]. 


TCLAS 


The TCLAS element specifies an element that contains a set of 
parameters necessary to identify incoming MSDUs (MAC Service Data 
Units) that belong to a particular TS (Traffic Stream) [3]. 
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2. Overview of IEEE 802.11 QoS 


IEEE 802.11 defines a way of providing prioritized access for 
different traffic classes (video, voice, etc.) by a mechanism called 
EDCA (Enhanced Distributed Channel Access). The levels of priority 
in EDCA are called access categories (ACs) and there are four levels 
(in decreasing order of priority): Voice, Video, Best-Effort, and 
Background. Prioritized access is achieved by using AC-specific 
values for Contention Window (CW) and Arbitration Inter-Frame Space 
(AIFS). (Higher-priority categories have smaller values for minimum 
and maximum CW and AIFS.) 


A subset of the QoS mechanisms is defined in WMM -- a Wi-Fi Alliance 
certification of support for a set of features from an IEEE 802.1le 
draft (now part of IEEE 802.11). This certification is for both 
clients and APs and certifies the operation of WMM. WMM is primarily 
the implementation of the EDCA component of IEEE 802.1le. WMM uses 
the IEEE 802.1P classification scheme developed by the IEEE (which is 
now a part of the 802.1D specification). The IEEE 802.1P 
classification scheme has eight priorities, which WMM maps to four 
access categories: AC_BK, AC_BE, AC_VI, and AC_VO. The lack of 
support in WMM for the TCLAS (used in identifying an IP flow) has an 
impact on the QoS provisioning. The impact on WMM-based QoS 
provisioning is described in Sections 3 and 4. 


IEEE 802.11 defines the way a (non-AP) STA can request QoS to be 
reserved for an access category. Correspondingly, the AP can 
determine whether to admit or deny the request depending on the 
available resources. Further, the AP may require that Admission 
Control is mandatory for an access category. In such a case, the STA 
is expected to use the access category only after being successfully 
admitted. WMM-AC is a Wi-Fi Alliance certification of support for 
Admission Control based on a set of features in IEEE 802.11. 


The QoS signaling in IEEE 802.11 is initiated by the (non-AP) STA (by 
sending an ADDTS request). This specification references procedures 
in IEEE 802.11, WMM, and WMM-AC. 


3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 


There are two main types of interaction possible to provision QoS for 
flows that require Admission Control -- one where the MN initiates 
the QoS request and the network provisions the resources. The second 
is where the network provisions resources as a result of a PMIPv6 QoS 
request. In the second scenario, the LMA can push the QoS 
configuration to the MAG. However, there is no standard way for the 
AP to initiate a QoS service request to the MN. Recommendations to 
set up QoS in both these cases are described in this section. 
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3.1. MN-Initiated QoS Service Request 
3.1.1. MN-Initiated QoS Reservation Request 


This procedure outlines the case where the MN is configured to start 
the QoS signaling. In this case, the MN sends an ADDTS request 
indicating the QoS required for the flow. The AP/MAG obtains the 
corresponding level of QoS to be granted to the flow by using the 
PMIPv6 PBU/PBA sequence that contains the QoS options exchanged with 
the LMA. Details of the QoS provisioning for the flow are provided 


below. 
+----------- + 

+----+ +--+ +---+ +------- + 
| MN | ||AP| [mac] | | IMA | 
+-+--+ ++-++--+-+-++ +---+---+ 

| | | | 
4+--------------------------------------- === === === === === === - + 
| (0) establish session with mobile network 
4+-------------------------------------- == === === === === === === + 

| | | | 
4+------------- + 
|upper-layer | | | | 
[notification | | | | 
+-+-+-+-+-+-+-+ | | | 

| | | | 

| ADDTS Request (TCLAS (opt) , TSPEC) , AC| | 

E e E re ee ee ee tie > 

| (1) —--->|PBU (QoS eisai | 

| a >| 

| | | | Policy 

| | | PBA (QoS option) (3) |<----- > 

| ee eee | 

|<---- 

hee PAE E A eat | | 

eae E | | 

| (4) | | 


Figure 2: MS-Initiated QoS Service Request 


In the use case shown in Figure 2, the MN initiates the QoS service 
request. 


(0) The MN establishes a session as described in steps 1-4 of Use 
Case 2 (MAG-Initiated QoS Service Request) in Section 3.1 of [1]. 
At this point, a connection with a PMIPv6 tunnel is established 
to the LMA. This allows the MN to start application-level 
signaling. 
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(1) The trigger for the MN to request QoS is an upper-layer 
notification. This may be the result of end-to-end application 
signaling and setup procedures (e.g., SIP [10]). 


Since the MN is configured to start QoS signaling, it sends an 
ADDTS request with TSPEC and TCLAS identifying the flow for which 
QoS is requested. 


It should be noted that WMM-AC specifications do not contain 
TCLAS. When TCLAS is not present, there is no direct way to 
derive flow-specific attributes like Traffic Selector in PMIPv6. 
In this case, functionality to derive IP flow details from 
information in upper-layer protocols (e.g., SIP [10]) and 
associate them with a subsequent QoS request may be used. This 
is not described further here, but it may be functionality in an 
Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). 
It should be noted that an ALG or DPI can increase the complexity 
of the AP/MAG implementation and affect its scalability. If no 
TCLAS is derived, the reservation applies to all flows of the MN. 
Parameter mapping in this case is shown in Table 2. 


(2) If there are sufficient resources at the AP/WLC to satisfy the 
request, the MAG sends a PBU with QoS options, Operational Code 
ALLOCATE, and the Traffic Selector identifying the flow. The 
Traffic Selector is derived from the TCLAS to identify the flow 
requesting QoS. IEEE 802.11 QoS parameters in TSPEC are mapped 
to PMIPv6 parameters. The mapping of TCLAS to PMIPv6 is shown in 
Table 1. TSPEC parameter mapping is shown in Table 4. 


If TCLAS is not present (when WMM-AC is used), TCLAS may be 
derived from information in upper-layer protocols (as described 
in step 1) and populated in the Traffic Selector. If TCLAS 
cannot be derived, the Traffic Selector field is not included in 
the QoS options. 


(3) The LMA obtains the authorized QoS for the flow and responds to 
the MAG with Operational Code set to RESPONSE. Mapping of PMIPv6 
to IEEE 802.11 TCLAS is shown in Table 1, and mapping of TSPEC 
parameters is shown in Table 4. 


Reserved bandwidth for flows is calculated separately from the 
non-reserved session bandwidth. The Traffic Selector identifies 
the flow for which the QoS reservations are made. 


If the LMA offers downgraded QoS values to the MAG, it should 
send a PBU to the LMA with Operational Code set to DE-ALLOCATE. 
(The LMA would respond with PBA to confirm completion of the 
request.) 
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(4) The AP/MAG provisions the corresponding QoS and replies with 
ADDTS Response containing authorized QoS in TSPEC, the flow 
identification in TSPEC, and ResultCode set to SUCCESS. 


The AP polices these flows according to the QoS provisioning. 


In step 3, if the LMA sends a downgraded QoS or a PBA message 
with status code CANNOT_MEET _QOS_SERVICE_REQUEST (179), then the 
AP should respond to the MN with ADDTS Response and ResultCode 
set as follows: 


- for downgraded QoS from LMA, ResultCode is set to 
REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from 
LMA are mapped to TSPEC as per Table 4. This is still a 
rejection, but the MN may revise the QoS to a lower level and 
repeat this sequence if the application can adapt. 


- if LMA cannot meet the QoS service request, ResultCode is set 
to TCLAS_RESOURCES_EXHAUSTED. 


Either REJECTED_WITH_SUGGESTED_CHANGES or 
TCLAS_RESOURCES_EXHAUSTED results in the rejection of the QoS 
reservation, but it does not cause the removal of the session 
itself. 
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3.1.2. MN-Initiated QoS De-allocation Request 


QoS resources reserved for a session are released on completion of 
the session. When the application session completes, the LMA or the 
MN may signal for the release of resources. In the use case shown in 
Figure 3, the MN initiates the release of QoS resources. 


4+----------- + 

4+----+ +--+ +---+ 4+------- + 

| MN | |AP| |MAG| | LMA | 

4+-+--+ ++-++--+-+-++ 4+---+---+ 
| | | | 

4+------------------------------------------------------------- + 


(0) Establishment of application session 
and reservation of QoS resources 


| | 
| | 
| (Session in progress) | 
| | 
| | 


Release of application session 


DELTS Response (TS INFO) (2) 


Figure 3: MN-Initiated QoS Resource Release 
(0) The MN establishes and reserves QoS resources. When the 
application session terminates, the MN prepares to release QoS 


resources. 


(1) The MN releases its own internal resources and sends a DELTS 
Request to the AP with TS (Traffic Stream) INFO. 


(2) The AP receives the DELTS request, releases local resources, and 
responds to the MN with a DELTS response. 
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(3) The MAG initiates a PBU, with the Operational Code set to 
DE-ALLOCATE, and with the Traffic Selector constructed from TCLAS 
and PMIPv6 QoS parameters from TSPEC. 


When TCLAS is not present, the MAG should de-allocate all flows 
with the same access category as indicated in the DELTS Request. 
In the typical case, if the client does not support TCLAS and 
only MN-initiated QoS Service requests are supported, then the 
MAG will have at most one QoS Service request per access 
category. 


(4) LMA receives the PBU and releases local resources. The LMA then 
responds with a PBA. 


It should be noted that steps 3 and 4 can proceed independently of 
the DELTS Response (step 2). 


LMA-Initiated QoS Service Request 
1. LMA-Initiated QoS Reservation Request 


This section describes the case when the QoS service request is 
initiated by the LMA. For example, an application such as voice may 
request the network to initiate configuration of additional QoS 
policy as in [8], Section 7.4.2. In the current WLAN specifications, 
there is no standard-defined way for the AP to initiate a QoS service 
request to the MN. As a result, when the MAG receives a QoS request 
from the LMA, it does not have any standard mechanisms to initiate 
any QoS requests to the MN over the access network. Given this, the 
PMIPv6 QoS service requests and any potential WLAN service requests 
(such as described in Section 3.1) are handled asynchronously. 


The PMIPv6 QoS service requests and WLAN QoS service request could 
still be coordinated to provide an end-to-end QoS. If the MAG 
receives an Update Notification (UPN) request from the LMA to reserve 
QoS resources for which it has no corresponding QoS request from the 
MN, the MAG may, in consultation with the AP, provision a policy that 
can grant a subsequent QoS request from the MN. If the MN initiates 
QoS procedures after the completion of PMIPv6 QoS procedures, the AP/ 
MAG can ensure consistency between the QoS resources in the access 
network and QoS resources between the MAG and LMA. 


For example, if the MN is requesting a mean data rate of x Mbps, the 
AP and MAG can ensure that the rate can be supported on the network 
between MAG and LMA based on previous PMIPv6 QoS procedures. If the 
MN subsequently requests data rates of x Mbps or less, the AP can 
accept a request based on the earlier PMIPv6 QoS provisioning. For 
the case where there is a mismatch, i.e., the network does not 
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support the x Mbps, then either the MAG should renegotiate the QoS 
resource and ask for increased QoS resources or the AP should reject 
the QoS request. 


3.2.2. Discussion on QoS Request Handling with IEEE 802.1laa 


The network-initiated QoS service request scenario poses some 
challenges outlined here. IEEE 802.11 does not provide any 
mechanisms for the AP to initiate a QoS request. As a result, the 
AP/MAG cannot explicitly make any reservations in response to a QoS 
reservation request made using UPN. IEEE 802.1laa [5] (which is an 
amendment to IEEE 802.11) has a mechanism that enables the AP to ask 
the client to reserve QoS for a traffic stream. It does this via the 
ADDTS Reserve Request. The ADDTS Reserve Request contains a TSPEC, 
an optional TCLAS, and a mandatory stream identifier. The 
specification does not describe how the AP would obtain such a stream 
identifier. As a result, there needs to be a new higher-layer 
protocol defined that is understood by the MN and AP and that 
provides a common stream identifier to both ends. Alternately, the 
IEEE 802.1llaa specification could be modified to make the usage 
optional. When (or if) the stream identifier is made optional, the 
TCLAS can provide information about the traffic stream. 


Appendix A outlines a protocol sequence with PMIPv6 UPN / Update 
Notification Acknowledgement (UPA) if the above IEEE 802.1laa issues 
can be resolved. 
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3.2.3. LMA-Initiated QoS De-allocation Request 


QoS resources reserved for a session are released on completion of 
the session. When the application session completes, the LMA or the 
MN may signal for the release of resources. In this use case, the 
network initiates the release of QoS resources. 


+----------- + 
+----+ +--+ +---+ +------- + 
| MN | |AP| |MAG| | LMA | 
+-+--+ ++-++--+-+-++ +---+---+ 
| | | | 
4+-------------------- ---- 5 = + 
| Establishment of application session 
| and reservation of QoS resources 
(Session in progress) | 
| Release of application session 
+-------------------- -- -- 5 5 5 5 5 = + 
| | Policy 
< ee 
ese 
| <------------------ 
<==] (1) 


| 
| 
| ----> | UPA (QoS, RESPONSE) 
| 
| 


DELTS Request (TS INFO) (3) 


DELTS Response (TS INFO) (4) | 


A 
| 
| 
| 
l 
| 
| 
| 
| 
| 
l 
| 
| 
| 
| 
| 
l 
l 
l 
| 
| 
l 
l 
| 
| 
| 
| 
| 
l 

N 


Figure 4: LMA-Initiated QoS Resource Release 


In the use case shown in Figure 4, the network initiates the release 
of QoS resources. When the application session terminates, the LMA 
receives notification of that event. The LMA releases local QoS 
resources associated with the flow and initiates signaling to release 
QoS resources in the network. 


(1) The LMA sends a UPN with QoS options identifying the flow for 


which QoS resources are to be released and Operational Code set 
to DE-ALLOCATE. No additional LMA QoS parameters are sent. 
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(2) The MAG replies with a UPA confirming the acceptance and 
Operational Code set to RESPONSE. 


(3) The AP/WLC (MAG) releases local QoS resources associated with the 
flow. The AP derives the corresponding access category from the 
Traffic Class (TC) field provided in the QoS option. In 
addition, if the AP supports TCLAS and the QoS option contains a 
Traffic Selector field, then the AP shall map the Traffic 
Selector into a TCLAS element. In the case where the AP does not 
support TCLAS (for example, an AP compliant with WMM-AC), then 
the AP shall only use the access category. The AP sends a DELTS 
Request with TS INFO identifying the reservation. 


(4) The MN sends DELTS Response confirming release. 


It should be noted that steps 3 and 4 can proceed independently of 
the UPA (step 2). 


4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters 
4.1. Connection Parameters 


TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream (MN 
MAC, TS ID). The IEEE 802.11 QoS reservation is for IEEE 802.11 
frames associated with an MN’s MAC address. 


The TCLAS element with Classifier 1 (TCP/UDP Parameters) is used to 
identify a PMIPv6 QoS flow. We should note that WMM-AC procedures do 
not support TCLAS. When TCLAS is present, a one-to-one mapping 
between the TCLAS-defined flow and the Traffic Selector is given 
below. 


QoS reservations in IEEE 802.11 are made for a traffic stream 
(identified in TCLAS) and correspond to PMIPv6 QoS session parameters 
(identified by the Traffic Selector). PMIPv6é QoS [1] specifies that 
when QoS-Traffic-Selector is included along with the per-session 
bandwidth attributes described in Section 4.3 below, the attributes 
apply at a per-session level. 


MAG <--> LMA (PMIPv6) | 


| (TCLAS Classifier 1)TCP/UDP IP 


Traffic Selector (IP flow) | 
| (TCLAS Classifier 1) DSCP 


Traffic Class (TC) | 


Table 1: IEEE 802.11 - PMIPv6 QoS Connection Mapping 
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If the MN or AP is not able to convey flow parameters in TCLAS, the 
QoS reservation request in IEEE 802.11 is derived as shown in 


Table 2. 
+------------------------------ 4+-------------------------- + 
| MN <--> AP (WMM) | MAG <--> LMA (PMIPv6) | 
+------------------------------ +-------------------------- + 
| (no IP flow parameter/TCLAS) | (a) applies to all flows | 
(b) derived out-of-band 
| User Priority (802.1D) | Traffic Class (TC) | 
| | (derived using Table 3) | 
+------------------------------ 4+-------------------------- + 


Table 2: WMM - PMIPv6 QoS Connection Mapping 


When WMM [4] is used, and TCLAS is not present to specify IP flow, 
one of two options apply for the MAG - LMA (PMIPv6) segment: 


(a) Bandwidth parameters described in Section 4.3 apply to all flows 
of the MN. This is not a preferred mode of operation if the LMA 
performs reservation for a single flow, e.g., a voice flow 
identified by an IP 5-tuple. 


(b) The IP flow for which the MN requests reservation is derived out- 
of-band. For example, the AP/MAG observes application-level 
Signaling (e.g., SIP [10]) or session-level signaling (e.g., 3GPP 
WLCP (WLAN Control Protocol) [7]), associates subsequent ADDTS 
requests using heuristics, and then derives the IP flow / Traffic 
Selector field. 


4.2. QoS Class 


Table 3 contains a mapping between access category (AC) and IEEE 
802.1D User Priority (UP) tag in IEEE 802.11 frames, and DSCP in IP 
data packets. The table also provides the mapping between AC and 
DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class). 
Mapping of QCI to DSCP uses the tables in [6]. 
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+----- + 
| acr | 
+----- + 
Mae 
| 2 | 
| 3 | 
lis el 
|5] 
6 
Ra 
| 8 | 
| 
+----- + 


Wi-Fi PMIPv6 QoS 


ie Se +--+ 
DSCP | 802.1D UP | AC 
See +--+ 
EF | 6 (VO) | 3 AC_vo 
EF |  6(VO) | 3 AC_vo 
EF | 6 (VO) | 3 AC_VvO 
AF41 |  5(VI) | 2 AC_VI 
AF31 | 4 (CL) | 2 AC_VI 
AF32 | 4 (CL) 2 AC_VI 
AF21 3 (EE) 0 AC_BE 
AF11 | 1 (BE) | 0 AC_BE 
BE |  0(BK) | 1 AC_BK 
Se ee ee +--+ 


+ 
| 

+ 
| 
| 
| 
| 
| 
| 

+ 


Example Services 


conversational voi 
conversational vid 
real-time gaming 
buffered streaming 
signaling 

buffered streaming 
interactive gaming 
web access 

email 


Table 3: QoS Mapping between QCI/DSCP, 802.1D UP, AC 


The MN tags all data packets with DSCP and IEEE 802.1D UP 
corresponding to the application and the subscribed policy or 
n. The AP polices sessions and flows based on the 
configured QoS policy values for the MN. 


authorizatio 


For QoS rese 


rvations, 


June 2015 


---+ 


ce 
eo 


TSPEC uses WMM-AC values and PMIPv6 QoS uses 
corresponding DSCP values in Traffic Class (TC). IEEE 802.1 
Access Category AC_VO and AC_VI are used for QoS reservations. AC_BE 
and AC_BK should not be used in reservations. 


1 Qos 


When WMM-AC specifications that do not contain TCLAS are used, it is 
only possible to have one reservation per Traffic Class / access 
category. PMIPv6 QoS will not contain any flow-specific attributes 


like Traffic Selector. 


4.3. Bandwidth 


Bandwidth parameters that need to be mapped between IEEE 802.11 and 
PMIPv6 QoS are shown in Table 4. 


sna a ceca a a tea E fem ee ee ea + 
| MN <--> AP(IEEE 802.11) | MAG <--> LMA (PMIPv6) | 
5 a aaa a re ie aia ee aa a t= SSS + 
Mean Data Rate, DL Guaranteed-DL-Bit-Rate 
Mean Data Rate, UL Guaranteed-UL-Bit-Rate 
| Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate | 
| Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate | 
E E E fe Sees Sas SS as denans nanna + 
Table 4: Bandwidth Parameters for Admission-Controlled Flows 
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In PMIPv6 QoS [1], services using a sending rate smaller than or 
equal to the Guaranteed Bit Rate (GBR) can assume, in general, that 


congestion-related packet drops will not occur [8]. If the rate 
offered by the service exceeds this threshold, there are no 
guarantees provided. IEEE 802.11 radio networks do not offer such a 


guarantee, but [4] notes that the application (service) requirements 
are captured in TSPEC by the MSDU (MAC Service Data Unit) and Mean 
Data Rate. The TSPEC should contain Mean Data Rate, and it is 
recommended that it be mapped to the GBR parameters, Guaranteed-DL- 
Bit-Rate and Guaranteed-UL-Bit-—Rate in PMIPv6 QoS [1]. 


IEEE 802.11 TSPEC requests do not require all fields to be completed. 
[4] specifies a list of TSPEC parameters that are required in the 
specification. Peak Data Rate is not required in WMM; however, for 
MNs and APs that are capable of specifying the Peak Data Rate, it 
should be mapped to MBR (Maximum Bit Rate) in PMIPv6 QoS. The AP 
should use the MBR parameters Aggregate-Max-DL-Bit-—Rate and 
Aggregate-Max-UL-Bit-Rate to police these flows on the backhaul 
segment between MAG and LMA. 


During the QoS reservation procedure, if the MN requests Mean Data 
Rate, or Peak Data Rate in excess of values authorized in PMIPv6 QoS, 
the AP should deny the request in an ADDTS response. The AP may set 
the reject cause code to REJECTED_WITH_SUGGESTED_CHANGES and send a 
revised TSPEC with Mean Data Rate and Peak Data Rate set to 
acceptable GBR and MBR, respectively, in PMIPv6 QoS. 


5. Security Considerations 


This document describes mapping of PMIPv6 QoS parameters to IEEE 
802.11 QoS parameters. Thus, the security in the WLAN and PMIPv6 
signaling segments and the functional entities that map the two 
protocols need to be considered. IEEE 802.11 [3] provides the means 
to secure management frames that are used for ADDTS and DELTS. The 
PMIPv6 specification [9] recommends using IPsec and IKEv2 to secure 
protocol messages. The security of the node(s) that implement the 
QoS mapping functionality should be considered in actual deployments. 


The QoS mappings themselves do not introduce additional security 
concerns. 
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Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.1laa 


E + 
part aa E, +------- + 
| mn | ||AP| [mac] | | IMA | 
+-+--4+ +4+-+4--+-4-4+4 +---+---+ 
| | | | 
$------ 55-55-55 5-5-5 5-5 5 5 5 5 5 5 5 5 5 5-5 - === + 
| (0) establish session with mobile network 
ee ee Se et Se ee eee + 
| | | | 
| | | | Policy 
| | | [Seopa e 
| | | UPN (QoS opt (2) | Update (1) 
| ADDTS Reserve Request | |< SS Su Ora a 
(TCLAS, TSPEC) (3) ad | 
<———— -— -— 
| ADDTS Reserve Response | 
| (TCLAS, TSPEC) (4) | | 
| | 
| 


Figure 5: LMA-Initiated QoS Service Request with 802.1laa 


In the use case shown in Figure 5, the LMA initiates the QoS service 
request and IEEE 802.llaa is used to set up the QoS reservation in 
the Wi-Fi segment. 


(0) The MN sets up a best-effort session. This allows the MN to 
perform application-level signaling and setup. 


(1) The policy server sends a QoS reservation request to the LMA. 
This is usually sent in response to an application that requests 
the policy server for higher QoS for some of its flows. 


The LMA reserves resources for the flow requested. 


(2) The LMA sends a PMIPv6 UPN (Update Notification) [2], as outlined 
in Section 3.2.1, to the MAG with Notification Reason set to 
QOS_SERVICE_REQUEST and Acknowledgement Requested flag set to 1. 
The Operational Code in the QoS option is set to ALLOCATE, and 
the Traffic Selector identifies the flow for QoS. 
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The LMA QoS parameters include Guaranteed-DL-Bit-Rate/Guaranteed- 
UL-Bit-Rate and Aggregate-Max-DL-Bit-Rate/Aggregate-Max-UL-Bit- 
Rate for the flow. The reserved bandwidth for flows is 
calculated separately from the non-reserved session bandwidth. 


If there are sufficient resources to satisfy the request, the AP/ 
MAG sends an ADDTS Reserve Request (IEEE 802.1laa) specifying the 
QoS reserved for the traffic stream, including the TSPEC and 
TCLAS elements mapped from the PMIPv6 QoS Traffic Selector to 
identify the flow. 


PMIPv6 parameters are mapped to TCLAS (Table 1) and TSPEC 
(Table 4). If there are insufficient resources at the AP/WLC, 
the MAG will not send an ADDTS message and will continue the 
processing of step 5. 


The higher-level stream identifier in IEEE 802.1laa should be 
encoded as discussed in Section 3.2.2. 


MN accepts the QoS reserved in the network and replies with ADDTS 
Reserve Response. 


The MAG (AP/WLC) replies with a UPA confirming the acceptance of 
QoS options and Operational Code set to RESPONSE. The AP/WLC 
polices flows based on the new QoS. 


If there are insufficient resources at the AP in step 3, the MAG 
sends a response with UPA status code set to 
CANNOT_MEET_QOS_SERVICE_REQUEST (130). 
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